Designing invisible handcuffs : Formal investigations in institutions and organizations for multi-agent systems

norms in an institution specification Ins are subsumptions between descriptions stated in Lins, that is, elements of Γins\Γbridge or Ains\Abridge (see Definition 5.4). Concrete norms are, in contrast, subsumtpions between descriptions stated in Lbrute. The connections between the two is provided by the subsumptions of Ins to be found in Γbridge or Abridge. An example follows which clarifies the interaction between abstract and concrete norms within institutions. Example 5.2. (From abstract to concrete norms) Consider an institution supposed to regulate access to a set of public web services. It may contain the following norm: “it is forbidden to discriminate access on the basis of citizenship”. Suppose now a system has to be built which complies with this norm. The first question is: what does it mean, in concrete, “to discriminate on the basis of citizenship”? The system designer should make some concrete choices for interpreting the norm and these choices should be kept track of in 2It is worth stressing that more than just two abstractness levels could in principle be represented, depending on how many sublanguages are considered. As shown in Chapter 2, abstractness and concreteness are, in the first instance, attributes of contexts w.r.t. other contexts. In general, a norm is abstract/concrete if it pertains to an abstract context and, respectively, to a concrete one. In this chapter, by considering just two sublanguages (Lins and Lbrute), we will work with only two levels. 128 Institutions as TBoxes order to explicitly link the abstract norm to its concrete interpretation. The problem can be represented as follows. The abstract norm is formalized as described in Section 2.5.1: the statement “it is forbidden to discriminate on the basis of citizenship” amounts to the statement “after every execution of a transition of type DISCR(i, j) the system always ends up in a violation state”. Together with the norm also some intuitive background knowledge about the discrimination action needs to be formalized. Here, as well as in the rest of the examples in the chapter, we provide just that part of the formalization which is strictly functional to show how the formalism works in practice. Formulae 5.5 and 5.6 express two effect laws: if the requester j is Dutch, then after all executions of transitions of type DISCR(i, j) j is accepted by i. If it is not, then all the executions of the transitions of the same type have as effect that it is not accepted. ∀DISCR(i, j).viol ≡ > (5.4) dutch( j) v ∀DISCR(i, j).accepted( j) (5.5) ¬dutch( j) v ∀DISCR(i, j).¬accepted( j) (5.6) The rest of the axioms concern the translation of the abstract type DISCR(i, j) to concrete transition types. Formula 5.7 refines it by making explicit that a precise if-then-else procedure counts as a discriminatory act of agent i. Formulae 5.8 and 5.9 specify which messages of i to j count as acceptance and rejection. If the designer uses transition types SEND(msg33, i, j) and SEND(msg38, i, j) for the concrete system specification, then Formulae 5.8 and 5.9 are bridge axioms connecting notions belonging to the institutional alphabet (to accept, and to reject) to concrete ones (to send specific messages). Finally, Formulae 5.10 and 5.11 state two intuitive effect laws concerning ACCEPT(i, j) and REJECT(i, j) by tuning the labeling of the states reachable via those transition types. if dutch( j)then ACCEPT(i, j) else REJECT(i, j) v DISCR(i, j) (5.7) SEND(msg33, i, j) v ACCEPT(i, j) (5.8) SEND(msg38, i, j) v REJECT(i, j) (5.9) ∀ACCEPT(i, j).accepted( j) ≡ > (5.10) ∀REJECT(i, j).¬accepted( j) ≡ > (5.11) It is easy to see, on the grounds of the semantics exposed in Definition 5.3, that the following concrete inclusion statement holds w.r.t. the specified institution: if dutch( j) then SEND(msg33, i, j) else SEND(msg38, i, j) v DISCR(i, j) (5.12) Notice also that this translation is aligned with the constraints stated in Formulae 5.5 and 5.6. This scenario exemplifies a pervasive feature of human institutions which, as extensively argued in [Grossi et al., 2006b], should be incorporated by electronic ones. Current formal approaches to institutions, such as ISLANDER [Esteva et al., 5.2 Explaining Institutions 129 2002], do not allow for the formal specification of explicit translations of abstract norms into concrete ones, and focus only on norms that can be specified at the concrete system specification level. What Example 5.2 shows is that the problem of the abstractness of norms in institutions can be formally addressed and can be given a precise formal semantics. 5.2.2 Non-arbitrariness of institutional specifications The scenario depicted in Example 5.2 suggests that, just by modifying an appropriate set of terminological axioms, it is possible for the designer to obtain a different institution by just modifying the sets of bridge axioms without touching the terminological axioms expressed only in the institutional language Lins. In fact, it is the case that a same set of abstract norms can be translated to different and even incompatible sets of concrete norms. Is such translation completely arbitrary? The answer is no. Example 5.3. (Acceptable and unacceptable translations of abstract norms) Reconsider again the scenario sketched in Example 5.2. The transition type DISCR(i, j) has been translated to a complex procedure composed by concrete transition types. Would any translation do? Consider an alternative institution specification Ins′ containing Formulae 5.4-5.6 and 5.10, and the following translation rule: ACCEPT(i, j) v DISCR(i, j) (5.13) Would this formula be an acceptable translation for the abstract norm expressed in Formula 5.4? The axiom states that transitions where i accepts j count as transitions of type DISCR(i, j). In fact, this is not intuitive because the abstract transition type DISCR(i, j) obeys some intuitive conceptual constraints (Formulae 5.5 and 5.6) that all its translations should also obey. In fact, the following inclusions hold in Ins′ as consequences of Formula 5.13: dutch( j) v ∀ACCEPT(i, j).accepted( j) (5.14) ¬dutch( j) v ∀ACCEPT(i, j).¬accepted( j) (5.15) These properties of the transition type ACCEPT(i, j) conflict with what follows from Formula 5.10: dutch( j) v ∀ACCEPT(i, j).accepted( j) (5.16) ¬dutch( j) v ∀ACCEPT(i, j).accepted( j) (5.17) Transitions of type ACCEPT(i, j) always bring about states of type accepted( j). Now, from Formula 5.15 and 5.17 it follows: ¬dutch( j) v ∀DISCR(i, j).⊥ (5.18) which would be quite odd. 130 Institutions as TBoxes The moral of the story is that when abstract transition or state types are translated, via appropriate inclusion axioms, to concrete ones, these concrete types should be compatible with the inheritance of the properties of the abstract types. This compatibility marks the boundaries within which translations are possible, and sets therefore precise logical limitations to the choice of the translation which cannot be fully arbitrary. To say it with Searle: “the selection of the X term [in the X counts as Y rule] is more or less arbitrary” ([Searle, 1995], p.49). The choice of the translation is only “more or less arbitrary” and not merely arbitrary in virtue of the properties of the concrete term which should be compatible with the properties of the abstract one. It is important to stress that this very same issue was already addressed, although from a slightly different perspective, in Section 2.4.3 of Chapter 2 where the notion of open-texture has been formally analyzed. Translations have boundaries because the to-be-translated terms are open-textured and not arbitrary. 5.2.3 Institutional modules and roles Viewing institutions as the impositions of institutional descriptions on systems’ states and transitions allows for analyzing the normative system perspective itself (i.e., institutions are sets of norms) at a finer granularity. We have seen that the terminological axioms specifying an institution concern complex descriptions of new institutional notions. Some of the institutional state types occurring in the institution specification play a key role in structuring the specification of the institution itself. The paradigmatic example in this sense are facts such as “agent i enacts role r” which will be denoted by state types rea(i, r) ([Dignum, 2003]). By stating how an agent can enact and ‘de-act’ a role r, and what normative consequences follow from the enactment of r, an institution describes expected forms of agents’ behavior while at the same time abstracting from the concrete agents taking part of the system. The sets of norms specifying an institution can be clustered on the grounds of the rea state types. For each relevant institutional state type (e.g., rea(i, r)), the terminological axioms which define an institution, i.e., its norms, can be clustered in (possibly overlapping) sets of three different types: the axioms specifying how states of that institutional type can be reached (e.g., how an agent i can enact the role r); how states of that type can be left (e.g., how an agent i can ‘de-act’ the a role r); and what kind of institutional consequences do those states bear (e.g., what rights and power does agent i acquire by enacting role r). Borrowing the terminology from work in legal and institutional theory ([Ruiter, 1997; Searle, 1995; Sartor, 2006]), these clusters of norms can be called, respectively, institutive, terminative and status modules. Remark 5.2. (Refraining from executing transition types) In what follows we will need to represent a form of negation of atomic transition types crudely corresponding to some notion of refraining. It is well-known that this is a hard issue to solve in dynamic logic-like 5.2 Explaining Institutions 131 formalisms like ours (see [Broersen, 2003]) and the readily available solution of using the negation ¬ of transition types is obviously too strong, since such negation is interpreted as the complement w.r.t. the whole state space S × S. We choose for a low-profile solution, which suits our needs without introducing heavy logical machinery that would not be used in our analysis. The non-logical alphabet of our language (see Definition 5.2) needs to be extended as follows: for every atomic transition type a, non_a is also an atomic transition type. Obviously, if a ∈ Lins then also non_a ∈ Lins and, respectively, if a ∈ Lbrute then also non_a ∈ Lbrute. In addition, any occurrence of an atomic transition type non_a in a TBox needs to be accompanied by the following role inclusion axiom: non_a v ¬a3. More elegant but complex solutions to the problem can be found in [Meyer, 1988] and in the comprehensive survey [Broersen, 2003].